perm filename DESCR[RDG,DBL]3 blob
sn#534512 filedate 1980-09-14 generic text, type C, neo UTF8
COMMENT ⊗ VALID 00015 PAGES
C REC PAGE DESCRIPTION
C00001 00001
C00003 00002 RLL TALK
C00005 00003 What's in a Language?
C00008 00004 Add to memo, next iteration:
C00009 00005 Comments about MEMO
C00013 00006 Criteria for Paper (esp AAAI)
C00015 00007 Comments re: AAAI Paper
C00018 00008 Documentation changes - full Document
C00021 00009 Short description (for AAAI Article)
C00032 00010 Version of Short PCohen rewrote (June 1980) [Taken from previous page]
C00035 00011 Mailed to NII (LENAT/CC) 18:50 26-June
C00046 00012 Mailed to CSD.NII@SCORE 15:41 3-July
C00058 00013 Received from NII 7-July (essentially final form)
C00068 00014 Language metaphor
C00072 00015 Ref:
C00077 ENDMK
C⊗;
RLL TALK
<<Table with missing leg for Problem 1; Hammer and Nail for Soln (rep'n lang)>>
<<Broken cup for Problem 2; Glue for Soln (rep'n lang)>>
Let us pause here and ask why LISP is in such common usage --
what advantages does it have over, say, Fortran (well, we know why not
Fortran) over, say, Pascal or the other "good" (structured) languages?
Answer is clear - Lisp is flexible and adaptable to new situations.
How does this happen: LISP code is identical, in form, to the data
it can use -- they are all S-Expressions. And LISP knows how to deal
with S-expressions in general, and hence can modify code with the
same ease as it can manipulate data in general.
What's in a Language?
1. Languages are inherently Linguistic entitites -- in the manner of
a grammar is. [See RWW's LS-pairs, ie Language/Structure]
2. A Rep'n Language attempts to correspond to the "real" world --
Representation is both an interpretation and a set of symbols
Language part of a representation
Language: a set of words and a grammar. Note this is asemantic.
Representation: a mapping between words in a language and objects,
relationships, etc. in the (some) world.
Note that a representation is also a language.
Representation Language: a scheme for constructing and augmenting
a representation, including tools for facilitating same.
Note than a representation language IS A representation and a language.
Representation Language Language: a scheme for constructing and augmenting
a representation language, including tools for facilitating same.
Note than a representation language language IS A representation language.
Glossary:
Language - Linguistic entity
Representation - See SIGART, p. 68-9 for defn, p.5 for illustration of difficulties
Represenatation Language - Corresponds to "real world" IN NATURAL WAY -
so the pieces are easy to manipulate
Representational Components - pieces used in a representational languages
Add to memo, next iteration:
1. Glossary:
Language, Representation, Rep'n Language, Semantics
rll, RLL-1,
Slot Type, slot, unit, proposition, class of units, typical member, defalts
2. Example of RLL in action - perhaps spill problem (with its control process)
Comments about MEMO
∂17-Aug-80 1335 CSD.FREEMAN at SU-SCORE Re: Memo, still just about done.
Date: 17 Aug 1980 1334-PDT
From: CSD.FREEMAN at SU-SCORE
Subject: Re: Memo, still just about done.
To: RDG at SU-AI
In-Reply-To: Your message of 17-Aug-80 0112-PDT
I couldn't get to any of the files on the IFS, I tried to get a manual
on the altos but they were out as of friday. Help facilities are non-
existent....I really would like a copy of appenices C, D, and maybe E.
pg 6 new slot => new slots
pg 21 It is confusing from 5.5 to 5.6. I know you realize this as ***here***
is used.
pg 21 Where is footnote 6, referenced in 5.6.
pg 22 footnote 18 has already been used....
pg 22 (An excellent article by ... of view.) is not a sentence....
pg 22 random paragraph starting with "the range of tasks..."
pg 23 RPSW "AMORD, TMS ..."
Basically it seems pretty good, but then I'm not an expert at any of the
subjects addressed. Who is writing E&E?
andy
-------
Date: 17 Aug 1980 0112-PDT
From: Russell Greiner <RDG at SU-AI>
Subject: Memo, still just about done.
To: csd.smith at SU-SCORE, csd.genesereth at SU-SCORE,
csd.lenat at SU-SCORE, csd.hines at SU-SCORE,
csd.freeman at SU-SCORE
CC: csd.greiner at SU-SCORE
Dave: I put it in the S mailbox.
I'm still not quite thru with sections 7 thru 9, but at the rate I'm
going, I never will be. Perhaps your comments can help guide me thru
those parts.
Also, there is a diagram I've prepared to accompany Appendix C, put I
can't xerox it, as I can't get into Marion's office.
Mike - I'll drop a copy off at your house tomorrw - well,
later today...
Doug - I left pages 20 on in your mailbox ... I ran out of copies
of the earlier stuff; but we've been over that anyway.
Finally, to get other copies:
Look in <GREINER>RLL>MEMO.*, on the Lassen IFS. That should include
MEMO.123 - Table of Contents, and Sections 1, 2 and 3
MEMO.S4 - Section 4
MEMO.5678 - Sections 5, 6, 7, 8, and 9; acknowledgement, and Appendices A and B
MEMO.SPEC - The diagram to accompany Appendix C.
MEMO.FNS - Appendix D, on functions, etc
MEMO.BIB - Appendix E, the bibliography
My password to the ALTO is IMDVS, if that becomes relevant.
Appendix C is stored on U.XGP[RLL,RDG], at SAIL.
Feel free to spool more copies, if you want.
I gotta get out of this place. I'll return sometime later today.
Give me a call at home if you want to meet earlier. (326-1730)
Russ
Criteria for Paper (esp AAAI)
1) Precise Statement of our goals -
To develop a body of mechanisms (read language) in which one can
represent the components of a RL, and their interactions.
(Components include:
Slots, Inheritance Mechanism, Matchers, Verifiers, ?Semantics? )
Include hierarchy of existing pieces - taken from Klone, KRL, ...,
user can pick and choose
Note it is NOT required that we (explicitly) encode every possible rep'nal
construct -- our goal is to be able to develope such, readily.
2) Where does power derive?
i) Self-Description -- note LISP has this as well
ii) Right size conceptual chunks - to facilitate easy use
This like compiler - user specifies high-level construct,
which machine translates into lower level
3) Verification - RLL is a success when ____.
i) Given any new rep'n item, we can nod our head, realizing it could be done
ii) Others abandon their systems, realizing RLL's generality subsumes
such systems
Comments re: AAAI Paper
Date: 18 May 1980 1603-PDT
From: CSD.LENAT
Subject: AAAI Papers
To: CSD.GREINER
Very few were accepted (about one in four), including only some of the
program committee's papers. Ours was accepted, however, in the "clearly
accept" category, of which there were surprisingly few examples. Most
of the ones we finally accepted were originally calssified "good but not great".
I neglected to find out about (and didn't review) any other "local" papers,
so I don't know how Dave, Mike, etc. fared. Brachman's repr. paper was
rejected (he was on the committee, incidentally) as insubstantive. The
experience was a good one, overall; we got everything done in about 9
solid hours of work. Woody Bledsoe will be staying over to meet with me
some tomorrow; I'll look around for you if you're interested.
Doug
-------
Mailed to LENAT@SUMEX (CC Hazen) 17:23 26-June
Doug:
A copy of the paper was put in your mailbox, identical to the one on
Marion's desk. (Yes, both have lines drawn in...)
If you want to change the document, you'll probably want to use the
Window Edge command, typing (to Bravo) "WE10<esc>" -- this moves the screen
over to see the text.
(The file is <GREINER>RLL>AAAI1.BRAVO -- same password as usual.
Note the AAAI.BRAVO paper has NOT been kept up to date with the corrections.)
Things to consider deleting, if space gets tight:
1. Subtitles
2. Whole Mary example - its more trouble than its worth, especially as it's wrong.
3. Semantics part -- especially the footnote. (Not that it's uninterested, but at
$100/page, ....)
4. Part of the applications - where we assert that xxx is considering using RLL.
[We should add in Larry's eventual work, don't you think?]
I might meander it in the afternoon --
Russ
Documentation changes - full Document
RLL: The Ultimate Representation Language
RLL: The Ultimate Expert System Builder
RLL: The Ultimate ...
<<As TMS system, ala AMORD -- at least initial RLL>>
Awkward
FAST-CACHE, FAST-GET for GetValue
Fast-Cache for CacheValue
Fast-Put for PutValue
Add on ways of handling quantification
Note at end that we are changing it so each unt (well, each KB) knows how to
access its slots, ...
Short description (for AAAI Article)
Implementing a complex AI task using begins by designing and building a
suitable representation language, in which to express the primitives of
this domain are easy to express and manipulate. (eg Parsing Trees for NL,
or Experiment Planning for MOLGEN.) The representation language used in
one domain is very seldom borrowed and adaptated to serve for some other
application -- the facilities which were desirable assets for the original
task become limitations elsewhere. Most such languages are therefore
built essentially from scratch -- a very time consuming (and, we believe,
avoidable) task.
Realizing this problem, we built a language in which the components of a
representation language could be described and built, and integrated into
a new representation language. This Representation Language Language,
RLL, provides a body of high level constructs which the user can apply
when designing his new language, [significantly speeding up this first
step.] RLL includes a large library of "representational pieces", e.g.
including the mode of inheritance used by the Examples link of the Units
package, or the A-Kind-Of type of slot associated with FRL. A novice user
can easily design his system by simply choosing the precise amalgamation
of these pieces he wishes. RLL is then responsible for meshing these
parts together, to form a coherent and working whole.
A more advanced user can exploit RLL's mechanisms for designing new parts
-- for example, a new inheritance, or new type of format permissable for a
slot. He could then use these in the system he is building. Once again,
the use of high level operators (such as Create-New-Inheritance-Like(
InstanceOf )) will vastly lessen the time required to construct this
desired language (compared to using, say, CAR, CDR and COND).
While several people have expressed interest in using RLL for their
applications, the system has only recently become sufficiently stable to
permit others to use it. It has been involved in two small, internal
tasks -- an adventure game simulation and an exploration into a more
complete self-description of various of its parts, using lower-level
primitives.
This research has forced us to examine a variety of issues -- ranging from
"what's in a language" concerns, which asks just what are the constituent
parts of a representation language, to epistomological questions, such as
how to handle intentional objects, or syntactic slots.
The details of how RLL was designed can be found in [Greiner 1980]; and
our proposals for solving many of the outstanding issues and questions are
in [Greiner and Lenat 1980] and [Genesereth and Lenat 1980]. Finally,
Dave Smith's demand paging system, CORLL, frees RLL from InterLisp's 256K
storage limitation.
Ref:
Genesereth, Micheal, and Lenat, Douglas B., "?", HPP Working Paper 80-?,
June 1980.
Greiner, Russell, "A Representation Language
Language", HPP Working Paer 80-9.
Greiner, Russell and Lenat, Douglas B., "A Representation Language
Language", submitted to this AAAI.
Smith, David E., "CORLL: A Demand Paging System for Units", HPP Working
Paper 80-8, June 1980.
Version of Short PCohen rewrote (June 1980) [Taken from previous page]
Implementing a complex AI task often begins by designing and
building a suitable representation language, in which the primitives
of the domain are easy to express and manipulate. The representation
language used in one domain is seldom borrowed and adapted to
another, because the facilities that were assets for one task become
limitations elsewhere. For this reason, most such languages are built
from scratch. The goal of the RLL effort is to reduce the amount of
time expended in building a representation language, by providing a
Representation Language Language, that is, a language that provides
the user with the components of many representation languages, and
with the ability to integrate them. RLL contains a large library of
"representational pieces", for example, the mode of inheritance used
by the Examples link of the Units package, or the A-Kind-Of type of
slot used in the MIT Frames Representation Language, FRL. A novice
user can easily design a language simply by picking an amalgamation
of pieces; RLL is responsible for meshing them together into a
coherent and working whole. A more advanced user can exploit RLL's
mechanisms for designing new parts, for example, a new mode of
inheritance, or a new type of format for a slot. He could then use
these in the system he is building. The use of high level operators
(e.g. "Create-New-Inheritance-Like(Instance-Of)") will greatly lessen
the time required to construct the desired language.
The RLL system is an ongoing effort. It has recently been
used in two small, internal tasks, an adventure game simulation and
an exploration into a more complete self-description of various of
its parts, using lower level primitives.
Mailed to NII (LENAT/CC) 18:50 26-June
Short description (for NII's HPP Brochure)
Motivation
Implementing a complex AI task usually begins by building such a
representation language. This language is designed to facilitate the
expression and manipulation of the primitives of this particular domain.
Experience has shown that the language used in one domain is seldom
borrowed and adaptated to serve for some other application: The
facilities which were desirable assets for the original task become
limitations elsewhere. Most such languages are built essentially from
scratch -- a very time consuming (and, we believe, avoidable) task.
Task Description
To speed up this first step, we built a language which "knows" about the
components of representation languages in general. This Representation
Language Language, RLL, provides an extendable collection of high level
operators and constructs, which can be used to describe and build such
components. It can then integrate these pieces into a functional, new
representation language. The user can use these functions to design his
"personal" language, capable of dealing with the problems associated with
his specfic domain and application.
RLL's open-ended means there were be an extendable set of possible
representational pieces. The current system knows about slots, modes of
inheritance, specification for functions, etc. (Much of the nomenclature,
such as Unit and Slot, is taken from the UNITS package, described
earlier.) (A sample mode of inheritance is the one associated with the
Examples link of the Units package, which corresponds to "element-of".)
Most operators are methods for defining or refining such pieces. For
example, RLL allows the user to define the "Parents" slot as the union of
the "Mother" and "Father" slots -- that is, (the value of) the "Parents"
slot of an individual is a list consisting of (the value of) that person's
"Mother" slot, and (the value of) his "Father" slot. This brief
definition alone is sufficient to tell RLL everything it needs to know
about this slot. RLL will automatically invalidate the value stored for
Fred's parents if his mother remarries; and know that only some units may
have a Parents slots (viz. those which had both a Mother and Father slot
-- i.e. people).
RLL includes a large library of pre-fabricated "representational pieces".
In fact, a novice can easily design his language by simply choosing the
precise amalgamation of these pieces he wishes. RLL will then mesh these
parts together, to form a coherent and working whole.
A more advanced user can exploit RLL's mechanisms for designing new parts.
The "Father" example above illustrates the ease associated with defining a
new slot; designing a new inheritance, or new type of format is as easy.
As before, the host of high level operators considerably lessens the
complexity associated with constructing and integrating this new piece.
Using these parts (however they were derived,) as tools, the user can then
procede with his main task. If he later discovers limitations in this set
of facilities, he need only redesign the offending components. RLL's high
level operators make such modifications easy to perform; furthermore, RLL
will automatically perform any necessary reformatting of the existing data
to conform to this new, just defined set of conventions.
Current Applications
While several people have expressed interest in using RLL for their
applications, the system has only recently become sufficiently stable to
permit others to use it. It has been involved in two small, internal
tasks -- an adventure game simulation and an exploration into a more
complete self-description of various of its parts, using lower-level
primitives.
An brief overview of RLL's goals can be found in [Greiner & Lenat]. This
is expanded in [Greiner 1980], which illustrating many additional aspects
of RLL's design and implementation. Finally, an important stand-alone
submodule of RLL is its demand paging system, CORLL, which frees RLL from
InterLisp's 256K storage limitation. (See [Smith 1980].)
Ref:
Greiner, Russell, "A Representation Language Language", HPP Working Paper
80-9, June 1980.
Greiner, Russell and Lenat, Douglas B., "A Representation Language
Language", AAAI Conference, Stanford, 1980.
Smith, David E., "CORLL: A Demand Paging System for Units", HPP Working
Paper 80-8, June 1980.
∂Date: 27 Jun 1980 1442-PDT
From: Nii at SUMEX-AIM
Subject: Re: Short RLL Description
To: RDG at SU-AI
cc: lenat
In response to your message sent 26 Jun 1980 1850-PDT
Russ,
The piece you wrote is really nice and is much appreciated.
I'll go over it Doug to get his ok
penny
-------
∂Date: 3 Jul 1980 1119-PDT
From: CSD.NII at SU-SCORE
Subject: RLL article
To: csd.greiner at SU-SCORE, rdg at SU-AI
cc: csd.nii at SU-SCORE
I've fixed the first 2-3 paragraphs of the RLL article. It is
unprotected and is in my directory at SCORE (do not use the one
at Sumex) <csd.nii>broch.rll. We are fast reaching a deadline so
could you get it back to me as soon as possible.
penny
-------
∂Date: 6 Jul 1980 1403-PDT - Nii at SUMEX-AIM - Rll write-up
To: rdg at SU-AI
cc: nii, Lenat
Russ,
I did some text editing to the version you gave me to save time.
I don't believe I changed any meanings intended in the paper. Please
look is over and see if you are satisfied--it's in <nii>broch.rll@sumex.
Meta-comments
1. Try to avoid too many parenthetical remarks. They are reserved for
statements which can be skipped over. Either something is worth
saying or it isn't. I took out most of the parentheses and made them
into regular text.
2. Unnecesary uses of "this" and "that"'s. Since the text progression
is quite logical, I replaced most of them with "the" or repeated the
references.
3. Look out for parallel constructs--avoid split infinitives.
4. Use commas, ;, and -- appropriately.
Since English is my second language, I'm not the one to criticize other's
English. However, there are some heuristics that can be learned that
might make your writing task a little easier and smoother.
penny
-------
Mailed to NI@SUMEX (& LENAT/cc) 13:03 7-July
Penny,
That document seemed good. I have (only) a few suggsted modifications;
our words do seem to be converging. One more iteration? When?
Russ
Mailed to CSD.NII@SCORE 15:41 3-July
Motivation
RLL is a tool to facilitiate the building of expert programs quickly. It
is itself an expert program, whose domain of expertise is knowledge
representation.
Task Description
The standard first step taken in building an application program (in AI)
is the design and implementation of a language which will be used
represent the knowledge this program will use. Experience has shown that
the language developed in one application is seldom adaptated for use in
other programs. The features that were useful for the original problem
become limitations elsewhere. Thus, a specialized representation language
is redesigned and reimplemented for each application -- a very time
consuming task.
RLL (Representation Language Language) is designed to reduce the time
spent building such representation languages. It is a language which
"knows" about the components of representation languages in general. It
provides the user with an extendable collection of high level operators
and constructs which he can use to describe and build components of his
target language. After the user has specified the desirable features of
the target language, RLL integrates these components into a functional,
new representation language. In other words, a user can readily (and
rapidly) design a personalized language, exactly suited to the domain and
the application task at hand.
RLL's open-ended means there were be an extendable set of possible
representational pieces. The current system can deal with pieces such as
slots, modes of inheritance, and specification for functions. Slots
conform to the definition given in the UNITS package description,
appearing earlier. (In fact, RLL borrowed much of its nomenclature, as
well as software, from this system. [Footnote: One example is a
stand-alone submodule of RLL, which implements a demand paging system.
This frees RLL from InterLisp's 256K storage limitation. (See [Smith].])
UNITs also motivated an important mode of inheritance: the one associated
with its Examples link. (This relationship corresponds to set theory
notion of "element-of".) There is nothing in UNITS which corresponds to
our use of functional specification. We are currently exploring this
domain, which helps unify many outwardly diverse concepts, such as
processes, mechanisms, and slots.
The initial RLL system is itself a very versatile representation language.
For most tasks, the user can use it as he might any other representation
language. What distinguishes RLL is that the user is not forced to follow
the constraints imposed by this particular language; instead, he can mold
his copy of RLL to accomodate his particular task.
RLL derives this flexibility in two ways. First, RLL contains a large
library of largely independent, pre-fabricated "representational pieces".
For example, there are many (mutually incompatible) ways in which one can
associate facts with an object. One corresponds to UNIT's idea of a slot,
while another is to let each unit point the list of assertions in which it
is involves. (Consider how to represent "Fred is the Father of Mary".
Using slots, this means filling the "Father" slot of the unit Mary with
the value "Fred". In the second notation, the unit Mary would point to
the assertion "(Father Mary Fred)".) This first method, using explicit
slots, is "active" in the initial RLL system. If this proves
unsatifactory, a simple command will instruct RLL to switch to this second
system. From then on, (or, at least, until the user's next alterring
command,) this modified version of RLL will understand this different set
of instructions, and its reactions will follow this second convention.
Furthermore, RLL will automatically convert the user's existing data into
this new format.
To effectively use these varied components, RLL must "understand" what
each does, and how. This information allows RLL to mesh diverse parts
together, to form a coherent and working whole. As such, it should be
possible for the user to design a fairly arbitrary language by simply
choosing the precise amalgamation of these pieces he wishes; leaving to
RLL the responsibility, and headaches, of fitting them together.
Realizing this catalog of "chunks" will never be totally complete, RLL's
second approach towards generality are its collection of tools designed to
help the user fabricate new parts. These high-level operators can be used
to define a new component, (or type of component) or refine an existing
one.
For example, the user can define the "Parents" slot as the union of the
"Mother" and "Father" slots. That is, (the value of) the "Parents" slot
of an individual is a list consisting of (the values of) that person's
"Mother" and "Father" slots. This brief definition (Parent = Union(Mother
Father) ) is sufficient to tell RLL everything it needs to know about this
slot. RLL now knows to (automatically) invalidate the value stored for
Fred's parents if his mother remarries; and know that only some units may
have a Parents slots (viz. those which had both a Mother and Father slot
-- i.e. people).
Defining a new slot is trivial; designing a new inheritance, or new type
of format is as easy. The host of high-level operators considerably
lessens the complexity associated with constructing and integrating this
new piece.
These parts (however they were derived,) become the language the user can
use for his main task. If he later discovers limitations in this set of
facilities, he need only replace, or redesign the offending components.
RLL's collection of types of parts, and its high-level operators, make
either type of modification relatively simple. As shown above, RLL then
does the "busywork" -- such as reformatting the existing data to conform
to this new set of conventions.
Current Applications
While several people have expressed interest in using RLL for their
applications, the system has only recently become sufficiently stable to
permit others to use it. It has been involved in two small, internal
tasks -- an adventure game simulation and an exploration into a more
complete self-description of various of its parts, using lower-level
primitives.
An brief overview of RLL's goals can be found in [Greiner & Lenat]. This
is expanded in [Greiner], which illustrating many additional aspects of
RLL's design and implementation.
Ref:
Greiner, Russell, "A Representation Language Language", HPP Working Paper
80-9, July 1980.
Greiner, Russell and Lenat, Douglas B., "A Representation Language
Language", AAAI Conference, August 1980, Stanford.
Smith, David E., "CORLL: A Demand Paging System for Units", HPP Working
Paper 80-8, July 1980.
Received from NII 7-July (essentially final form)
RLL
Motivation
RLL is a tool to facilitiate the building of expert programs
quickly. It is itself an expert program, whose domain of expertise
is knowledge representation.
Task Description
The standard first step taken in building an application
program in AI is the design and implementation of a language that
(in which to)
represents the knowledge the program will use. Experience has shown
that the language developed in one application is seldom adaptated
for use in other programs. The features that were useful for the
original problem become limitations elsewhere. Thus, a specialized
representation language is redesigned and reimplemented for each
application -- a very time consuming task.
RLL (Representation Language Language) is designed to reduce
the time spent building such representation languages. It is a
language which "knows" about the components of representation
languages in general. It provides the user with an extendable
collection of high level operators and constructs which he can use to
describe and build components of his target language. After the user
has specified the desirable features of the target language, RLL
integrates these components into a functional, new representation
language. In other words, a user can readily and rapidly design a
personalized language, exactly suited to the domain and the
application task at hand.
RLL is an opn-ended language in which the user can add peices
of language not provided in RLL's standard repetoir. Currently RLL
can deal with pieces such as slots, modes of inheritance, and
specification of functions. Slots conform to the definition given in
the UNITS package (see page ). In fact, RLL borrowed much of its
nomenclature, as well as software, from UNITS. For example, it uses
one of UNITS main mode of inheritance, the Eample link. This
inheritance relationship corresponds to set theory notion of
"element-of". However, there is nothing in UNITS which corresponds
to RLL's use of functional specification. This domain is currently
being explored, because it would help unify many outwardly diverse
concepts, such as processes, mechanisms, and slots.
The initial RLL system is itself a very versatile
representation language. For most tasks, the user can use it as he
might any other representation language. What distinguishes RLL is
that the user is not forced to follow the constraints imposed by a
particular language; instead, he can mold his copy of RLL to
accomodate his particular task.
RLL derives this flexibility in two ways. First, RLL
contains a large library of largely independent, pre-fabricated
"representational pieces". For example, there are many (mutually
incompatible) ways in which one can associate facts with an object.
One corresponds to UNIT's idea of a slot, while another is the use of
pointer to a list or relevant assertions. For example, consider how
to represent "Fred is the Father of Mary". Using slots, "Father"
slot of the unit Mary would be filled with the value "Fred". Using
links, the unit Mary would point to the assertion "(Father Mary
Fred)". The first method, using explicit slots, is "active" in the
initial RLL system. If this proves unsatifactory, a simple command
will instruct RLL to switch to the second method. From then on,
(or, at least, until the user's next alterring command) the user
modified version of RLL will prevail. Furthermore, RLL will
automatically convert the user's existing data into the new format.
To effectively use the variety of components, RLL must
"understand" what each does, and how. This information allows RLL to
mesh diverse parts together to form a coherent and workable whole.
As such, it should be possible for the user to design a fairly
arbitrary language by simply choosing the precise amalgamation of the
pieces he needs, leaving to RLL the responsibility of fitting them
together.
Cataloging of possible components will never be totally
complete. RLL's second approach towards generality is its collection
of tools designed to help the user fabricate new parts. A set of
high-level operators are provided so that the user can define new
components or a type of components, or refine existing ones.
For example, the user can define the "Parents" slot as the
union of the "Mother" and "Father" slots. That is, the value of the
"Parents" slot of an individual is a list consisting of the values of
that person's "Mother" and "Father" slots. This brief definition,
Parent = Union(Mother Father), is sufficient to tell RLL everything it
needs to know about this slot. RLL now knows to automatically
invalidate the value stored for Fred's parents if his mother
remarries. Furthermore it knows that only some units may have a
Parents slots, i.e. those which have both a Mother and Father slots.
The language parts, however they were derived, become the
language the user can use for his task. If he later discovers
limitations in this set he need only replace or redesign the
offending components. RLL's collection of types of parts, and its
high-level operators, make modifications relatively simple. As shown
above, RLL then does the "busywork", such as reformatting the
existing data to conform to the set of new conventions.
Current Status
Although interests have been expressed in using RLL for a
variety of applications, the system has only recently become
sufficiently stable to permit others to use it. Thus far, it has
been used in two small internal tasks--an adventure game simulation
and an exploration into a more complete self-description of its
various parts using lower-level primitives.
Language metaphor
Representation Languages share many similiarities with natural languages,
such as English.
Both can be used to express facts about the world,
and in both cases, such descriptions are in terms of very high level, and "natural"
units.
Both are open-ended, and extendable --
new terms can be formed from old, using various established methods.
(New words can be created by adding a prefix to an existing word.
One can infer the meaning of "verbifying", as it applies a standard
method by verbifying to the noun, "verb".
Also, a word can take on a new, or extended meaning,
by using it in a new context.)
A language is more than just a dictionary of words;
it also includes a grammar which describes
how to use words to form higher level constructs,
such as Noun Phrase, Sentence, or Story.
RLL is like a very general purpose language,
which contains a large number of words, and a very encompassing grammar.
Many users will be able to use this, sans alterations.
What distinquishes RLL from most other representational languages is its
ability to change.
It can built not only new words,
but new and different grammars as well.
Most systems impose a fairly rigid set of conventions on what they can do,
and how.
The user has no choice but to conform to these standards,
which forces some applications into awkward contortions, if it is at all possible.
Like Dorothy in the Wizard of Oz, the frustrated
It achieves this generality by describing these each of notions precisely;
representing them within RLL's own formalisms
(much like reading an text on English, written in English).
These descriptions can then be used.
A user can combine the desired features
of several distinct languages to form
a new, specialized language, suited to his particular needs and goals.
Our eventual goal is to provide an entire catalog of these language
provides the ability to shift amoung languages -- to use German's
capability to string nouns together, and
Ref:
Extensible langauge, for describing extensibilites:
Davis, Randall, "Generalized procedure calling and content-directed invocation",
SIGPLAN Noices, Vol. 12, Nol 8, August 1977, pp. 45-54
Same general ideas - of bootstrapping down & down
Sandewall, Erik, "?", IJCAI 4
Smalltalk - idea of each unit knowing what to do
Fahlman "<10% not easy to represent, and require special fixes"
[see IJCAI-79, p.282 - in article re: AMORD]
Fox (IJCAI-79 282-4) - make things as explicit as possible - and declarative
Georgeff (IJCAI-79 330) - can add semantics to MetaRules easily
[use Cogn Econ to decide what needs to be recomputed]
Laubsh (IJCAI-79 516) [W German] {ATN w/Sem Nets} put concepts into Units,
with additional facts
Leitner, Henry H (Harvard) & Micheal W Freeman(Burroughs), (IJCAI-79 525)
store with "slot" what to do
Miller, G.A., E. Galanter, and K H Pribaum "Plans & the Structure of Behaviour,
New York: Holt, Rinehard & Winston, 1960. (see IJCAI-79 555)
"Major source of new plans is old plans."
Mostow & Hayes-Roth (IJCAI-79 601) - schema for heuristic search, w/slots for facts
IJCAI-79, 617 - AKO limiting - as meaning too many things, and all imprecisely
Semantics not pure (618)
"Prespecitifed useages of attached procedures is too restrictive"
(but they still stop shrt of real soln - ie they add own (deepter) conventions)
Hayes "Defense of Logic" - refers to building an interpreter for the interpreter
[see also Stefik's HPP-80-13, appearing in ?Artificial Intelligence? 1980]